Sistemas Operativos

Videos:
https://open.fing.edu.uy/courses/fsi/10/
https://open.fing.edu.uy/courses/fsi/11/
https://open.fing.edu.uy/courses/fsi/12/
https://open.fing.edu.uy/courses/fsi/13/
https://open.fing.edu.uy/courses/fsi/14/

Diapositivas:

[[sistemas_operativos_introduccion.pdf]]
[[sistemas_operativos_unix.pdf]]
[[sistemas_operativos_windows_introduccion.pdf]]
[[sistemas_operativos_windows_acceso_1.pdf]]
[[sistemas_operativos_windows_acceso_2.pdf]]

Introducción

Sistema Operativo: intermediario entre el hardware y los usuarios del sistema, encargado de realizar:
- la asignación eficiente de recursos entre los procesos o programas y usuarios del sistema
- proteger el sistema de programas (y usuarios) incorrectos o maliciosos
- mantener y proteger espacios de usuarios disjuntos o separados
- permitir a los usuarios el acceso a datos, programas y otros recursos
- ejecutar programas de usuarios
- optimizar la eficiencia total del sistema
- gestionar dispositivos de entrada y salida
Desde que el sistema inicia hasta que es apagado.

Motivación

Recursos controlados y protegidos por el Sistema Operativo:

CPU (Gestor de procesos)
Memoria (Gestor de memoria)
Almacenamiento en disco (File System)
Terminales, Impresoras
Acceso a la red / Ancho de banda (Networking)

Introducción

Trusted Computing Base

Porción de un sistema o aplicación en el cual tenemos que confiar en su seguridad.
La TCB debería ser:
- tan pequeña como sea posible
- tan confiable como sea posible
Típicamente el Sistema Operativo (o una gran parte de él) forma parte de la TCB.

Principios de Seguridad

Asegurar el eslabón (punto) más débil.
Defensa en profundidad.
Principio de menor privilegio.
Reducir la superficie de ataque.
Compartimentar (sandboxing).
Asegurar los valores por defecto.
Fallar en forma segura.
KISS (Keep It Simple).
Mantener secretos es difícil.
(Security Through Obscurity)

Se pueden aplicar a distintos niveles, por ejemplo:

A nivel de una sola aplicación.
Entre distintas aplicaciones.
Sistema operativo.
Networking.
Organizacional.

Problemas de seguridad a nivel S.O.

¿Como controlamos que personas pueden utilizar el sistema?
¿Como controlar los procesos que un usuario puede ejecutar?
¿Como controlar los recursos que un proceso puede acceder?
¿Como proteger entre sí a los procesos que comparten recursos del sistema?

Mecanismos de seguridad ofrecidos por los S.O.

Capa de abstracción sobre el hardware:
- Esconder los detalles de bajo nivel permite prevenir el acceso y el abuso de los mismos.
- Pero las capas de abstracción pueden ser evitadas.
Procesos.
Kernel vs user mode (modos de ejecución).
Memoria Virtual.
File Systems.
Autenticación.
Control de Acceso y Autorización.

UNIX

Conceptos preliminares

Pasted image 20240506225631.png

Información sobre usuarios (sujetos) se guarda en cuentas de usuario.
Cualquier privilegio permitido a un usuario puede guardarse en esta cuenta.
La identificación y autenticación verifican la identidad del usuario,
Esto permite al sistema asociar los privilegios de un usuario a cualquier proceso iniciado por éste.
Permisos sobre recursos (objetos) pueden asignarse por el administrador o el propietario.
Para decidir acceso a un recurso, el SO puede referirse a la identidad del usuario, a los privilegios establecidos para el sujeto y los permisos sobre el objeto.

Contexto de UNIX

Originalmente diseñado para pequeñas redes de computadoras, ambientes multi-usuario.
Desarrollado para ambientes amigables, labs. de investigación y Universidades.
Mecanismos de seguridad elementales; mejorados gradualmente.
Implementa DAC con granularidad a nivel de owner, group, other.
Existen versiones de Unix “seguras” con soporte multi-level security.

Security Architecture

Los controles de seguridad en UNIX no están contemplados en los objetivos de diseño iniciales.
Nuevos controles de seguridad se han incorporado, otros se fortalecieron a demanda.
Siempre intentando interferir lo menos posible con las estructuras existentes.
La seguridad es gestionada por administradores con mucha experiencia.

Principals (UID / GID) #parcial

Los principals son llamados user identities (UIDs) y group identities (GIDs).
Ambos son enteros de 16 bits.
#parcial
Algunos UIDs tienen significados especiales.
- El superusuario en unix es siempre 0.

Cuentas de usuario #parcial

Las informaciones sobre los principals son guardadas en cuentas de usuario y directorios home (personal).
Cada individuo debe tener su propia cuenta.
No deben haber cuentas grupales ¡tip!
Todas las cuentas deberían autenticarse de la misma forma.

Super-usuario, UID=0 y /etc/passwd y /etc/shadow

Cada cuenta se registra con una entrada en el archivo /etc/passwd
- y en el /etc/shadow.
La cuenta root es el superusuario.
Existen otras cuentas por defecto.
- siempre deberían estar bloqueadas ¡tip!

UID 0

El login name del usuario root no es lo que determina los permisos de ese usuario.
El UID es el que lo hace.
Si un usuario tiene UID 0, aunque no tenga como login root, es equivalente al superusuario.
Periódicamente hay que revisar /etc/passwd para verificar que hay una única cuenta con UID 0 y que a la vez tiene login root.

/etc/passwd #parcial

Es una tabla con los siguientes campos:
login : contraseña_encriptada : UID : GID : comentario : directorio_personal : shell_de_inicio
Dueño: root; grupo: root
Permisos: rw para el dueño, r para el resto.
- Programa /bin/passwd necesita SUID root para poder modificarlo.
La contraseña se movió a /etc/shadow

Pasted image 20240506230802.png

Grupos de usuarios

Cada usuario está presente en al menos un grupo de usuarios.
Agregar usuarios a grupos es una base conveniente para decisiones de control de acceso.
El GID de /etc/passwd es el grupo primario.
Ejecutando groups se pueden saber los grupos secundarios.

Sujetos (PID) #parcial

Los sujetos son los procesos del sistema.
Cada uno tiene un process ID (PID).
Se crean nuevos mediante fork o exec.
Cada proceso tiene asociado un UID/GID real, y uno efectivo.
- El UID real es heredado del padre.
- El UID efectivo es heredado del padre o del archivo que se está ejecutando.

Login y Passwords

Los usuarios se identifican mediante nombres de usuario y passwords.
Cuando un usuario se loguea, el proceso login verifica el usuario y password.
Si la verificación es exitosa, se cambia el UID/GID al del usuario y se ejecuta la shell de login.
Los passwords se cambian mediante el comando passwd.

/etc/shadow #parcial

Si está en el sistema, la contraseña se cambia por un + en /etc/passwd
Dueño: root; grupo: root.
Permisos: r para el dueño, nada para el resto.

Ejemplo

Pasted image 20240506233818.png
Los restantes campos están vacíos pues son valores por defecto.

Password hash

Objetos

Los objetos para el control de acceso incluyen: archivos, directorios, dispositivos, I/O, etc.
Están organizados en un sistema de archivos con estructura de árbol.

Inodos

Cada entrada de archivo en un directorio es un puntero a una estructura de datos llamada inodo.
Cada directorio tiene un puntero a sí mismo, el archivo '.', y un puntero a su padre, el archivo '..'.
Cada archivo tiene un dueño, usualmente el usuario que lo creó.
Cada archivo pertenece a un grupo.

Bits de permisos #parcial

Los permisos de los archivos (bits de permisos), se agrupan en tres tripletas.
Definen permisos de read, write, y execute, para el propietario, el grupo, y otros (resto del mundo).
- También se pueden especificar como números octales, separando los nueve permisos en 3 grupos de 3.
- Cada derecho de acceso está representado por un bit, el cual si está prendido (en 1), permite el acceso.
- La combinación de derechos es la suma de los números correspondientes.
- El permiso 777 da todos los accesos al dueño, grupo y mundo.

Pasted image 20240506234302.png

Permisos por defecto

Las utilidades UNIX, como editores o compiladores, usan típicamente los permisos 666 al crear un nuevo archivo.
Deben ajustarse con la mask.
Los permisos por defecto son derivados de un AND entre los bits por defecto y el inverso de la máscara. #parcial
Ver comando umask.
- Permite establecer el permiso por defecto. Pasa de ser 666 a lo seteado.

Interpretación en directorios

Cada usuario tiene un directorio home.
Se crean con el comando mkdir.
Para poner archivos en ese directorio, se deben tener los permisos adecuados.
- Permisos de lectura permiten a un usuario encontrar archivos en el directorio.
- Permisos de escritura permiten a un usuario agregar y borrar archivos al directorio.
- Permisos de ejecución se requieren para hacer el directorio el actual y para abrir/ejecutar archivos.

-> Para ejecutar a/b/c.sh, preciso permiso de ejecución en a , a/b y a/b/c.sh.

Control de acceso

Está basado en atributos de los sujetos (procesos) y de los objetos (recursos).
Las sistemas Unix clásicos asocian tres conjuntos de derechos de acceso, con cada recurso correspondientes a owner, grupo y world.
El superusuario no está sujeto a estos chequeos.

Chequeo de permisos

Si el uid indica que se es dueño del archivo, los bits de permisos de owner (o dueño) deciden si se tiene acceso.
Si no es dueño del archivo, pero el sujeto pertenece grupo dueño del archivo, se aplican los permisos del grupo.
Si no, se aplican los permisos de world (resto del mundo).
!! Se podría dar el caso en que el dueño del archivo tenga menos permisos que el grupo dueño o (world) el resto del mundo.

Contraseñas y políticas de complejidad de claves

Problema

Las contraseñas de los usuarios:

Son fáciles.
En general son palabras presentes en un diccionario o similares.
No nos gusta cambiarlas y solemos usar la misma contraseña para todo...
En un estudio del '90 se demuestra que un 24,2% de los passwords se quiebran con un simple diccionario (Klein 90).

Medidas para limitar el riesgo

Limitar la cantidad de login fallidos.
Evitar la repetición de contraseñas.
Obligar a que los usuarios las cambien.
Impedir que las contraseñas sean obvias.
Eliminar las cuentas sin uso.
Limitar el horario de uso del sistema.

SUID/SGID, sandboxing, logging y hardening

Necesitamos poder ejecutar procesos con privilegios de root.
Por ejemplo:
- Para escuchar en puertos < 1024.
- Para modificar la contraseña.
Solución adoptada en Unix:
- Set UserID (SUID)
- Set GroupID (SGID)
Programas con el SUID o SGID ejecutan con el UID o GID efectivo del usuario o grupo dueño del archivo. #parcial

SUID a root #parcial

En archivos con SUID root, el usuario que lo ejecuta obtiene estos privilegios durante la ejecución.
Algunos ejemplos:
- /bin/passwd: cambio de contraseña
- /bin/login: programa de login
- /bin/at: ejecución de programas batch
- /bin/su: cambiar el UID (switch User ID)
Debemos cuidar que estos programas hagan solo lo que deben hacer.

Riesgos de SUID

Si logramos engañar a un programa con SUID de root, estamos logrando acceso de root.
Estos programas deben procesar con mucho cuidado los parámetros de entrada.
Usemos SUID/SGID sólo cuando es estrictamente necesario.
Debemos controlar la integridad de estos programas (Tripwire, AIDE, Yafic).

Procedimiento

Proceso hace SUID 0.
El UID efectivo pasa a 0.
El proceso realiza lo que precisaba con root.
Termina, se copia el UID real al efectivo.
Sigue la ejecución.

Invocaciones controladas

Combinando ownership, permisos y programas SUID.
Otras técnicas complementarias:
- Jail root
- Containers o sandboxing
- Wrappers

Otros requerimientos

Además, en un sistema operativo se necesita:

El registro de eventos de auditoría del sistema y las aplicaciones del S.O (logging, syslog, gestión de logs, etc).
Instalación y configuración inicial del sistema (Hardening).
Gestión de configuración y actualizaciones de seguridad (patches) durante todo el ciclo de vida.

Windows

Introducción

En Unix, todos los objetos son tratados uniformemente como recursos. Sin embargo en Windows, el control de acceso puede ser ajustado individualmente a los distintos tipos de objetos.

Arquitectura de Windows

Pasted image 20240509185540.png

Los usuarios hacen llamadas a API’s para invocar los servicios del Sistema Operativo.
El cambio de contexto entre user y kernel mode es manejado a través de Local Procedure Call.
Los componentes del subsistema de seguridad en modo usuario son:
- El proceso de Logon (winlogon) => autentica
- Local Security Authority => crea un access token
- Security Account Manager => mantiene BD usuarios
  #parcial

El registro

Es la base central de datos de configuración de Windows.
Para modificar/desplegar el contenido usamos el editor de registro: regedit.exe o regedt32.exe.
Una entrada o nodo del registro es un grupo de claves, subclaves y valores.
Claves de más “alto nivel” predefinidas de la registry:
- HKEY_CLASSES_ROOT asociación de extensiones de archivos.
- HKEY_CURRENT_USER configuración del usuario actualmente logueado.
- HKEY_LOCAL_MACHINE configuración de la computadora.
- HKEY_USERS profiles de los usuarios cargados en el sistema.
- HKEY_CURRENT_CONFIG profile del hardware del sistema usado por la computadora cuando se inicia.

Entradas relevantes para la seguridad del sistema

HKEY_LOCAL_MACHINE/SAM
HKEY_LOCAL_MACHINE/Security
HKEY_LOCAL_MACHINE/Software
HKEY_CURRENT_CONFIG
HKEY_USERS/DEFAULT

Modificando el registro, un atacante puede modificar el comportamiento del sistema. Es necesario proteger la integridad del registro.

Un problema potencial es cuando una clave no está definida explícitamente, p.e.: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/SecurePipeServers/Winreg
Si NO existe la clave, se permite acceder remotamente al registro sin realizar chequeos!!

Dominios

Definición: Colección de máquinas que comparten la base de cuentas de usuarios y políticas de seguridad.

Pueden formarse jerarquías de dominios.
Existe un Domain Controller (DC), luego otras máquinas se unen al dominio.
Pueden haber más de un DC.
Las actualizaciones son propagadas usando el modelo de multimaster replication.

Active Directory

Implementación de servicio de directorio en Win2000.
Árbol de objetos con tipo.
Los objetos se identifican con GUID (Global Unique Identifier).
Los contenedores son objetos que pueden contener otros objetos.

Control de acceso

Más complejo que el control de acceso en un filesystem típico.
Los objetos sobre los que se aplica son: archivos, claves del registro, objetos del AD, etc.
Mecanismos para estructurar políticas: grupos, roles y herencia.

Principals

Son las entidades activas en las políticas de seguridad, esto es, objetos sobre los que se puede permitir o denegar el acceso.
Por ejemplo: usuarios, alias, usuario de dominio, grupos o máquinas.
Asocian <username, SID> (Security IDentifier).
Hay distintos “tipos”: Local / Domain / Universal.

Grupos globales

Un grupo (global) es una colección de SIDs manejada por el DC.
Tiene su propio SID, para que puedan anidarse.
Constituyen una capa de control intermedia, esto es:
Se da permisos a un grupo para acceder a un objeto, y luego se da permisos a los usuarios sobre el objeto agregando usuarios al grupo.

Alias

Son un conjunto de SIDs de usuarios y grupos manejados por el DC o por el LSA (Local Security Authority).
No pueden ser anidados.
Se utilizan para crear roles locales.

Formato SID

Formato:

: la letra S.
: el número de revisión.
: identifier authority (48-bit).
: subauthority (32-bit). Tantas como se quiera o ninguna.
: identificador relativo, único (RID) en el espacio de nombres de la autoridad.

Ejemplos

Everyone:
SYSTEM:

Principal con el que ejecuta localmente el Sistema Operativo en una maquina.
Administrator:

Cuenta de usuario creada durante la instalación del S.O.
Administrators:

Grupo predefinido (built-in) del sistema con privilegio de administrador. Inicialmente integrado por la cuenta Administrator.
Domain Administrators:

Grupo global, miembro del alias Adminmistrators en todas las maquinas del dominio.
Cuenta Guest:

Consulta de información

Podemos ver información de los principals con los siguientes comandos:

Usuarios locales y aliases:
> net user
> net localgroup
Usuarios, grupos y aliases de dominio: 
> net user /domain
> net group /domain
> net localgroup /domain
Miembros de un grupo: 
> net group “UK Employees” /domain
Información de un usuario: 
> net user diego /domain

También ver los SID de los usuarios de un equipo:
Correr regedt32.exe y acceder a HKEY_USERS.

Sujetos #parcial

Son las entidades activas en el Sistema Operativo: threads o procesos.
Las credenciales de seguridad para un sujeto se guardan en access tokens.
- Contiene la Unión de todos los privilegios asignados a los SIDs.
SIDs sirven como atributos de identidad y autorización.
- análogo a los PID de linux

Privilegios

Controlan el acceso a los recursos del sistema.
Se asignan a usuarios, grupos y alias por máquina.
Son diferentes a los derechos de acceso (access rights).
Ejemplos:
- backup de archivos y directorios
- generar auditorías de seguridad
- apagar el sistema

Mecanismo de Autenticación de Usuarios #parcial

Se encarga la winlogon.exe y GINA DLL, iniciado por la secuencia de atención segura (CTRL+ALT+DEL).
Se pasa la información al LSA (lsass.exe, Local Security Authority).
LSA invoca paquete de autenticación que retorna el SID del usuario y los SID de los grupos a los que pertenece.
LSA genera access token y se lo pasa el logon process.

Creación de Sujetos

En el próximo paso, el proceso de logon inicia la shell de inicio (explorer.exe).
Esto se hace en una nueva sesión bajo el usuario (principal) que se ha autenticado.
Estos procesos son los sujetos para el propósito del control de acceso.
Un proceso crea nuevos procesos (locales) invocando a CreateProcess.
Cada proceso obtiene una copia del token del proceso padre.

Objetos

Security Descriptors #parcial

Son entidades pasivas en las operaciones de acceso.
Hay al menos 2 tipos de objetos:
- ejecutables (procesos/threads)
- filesystem (archivos/directorios).
La DACL (Discretionary ACL) determina quién tiene acceso.
La SACL (System ACL) define la audit policy.

Permisos / access rights

Un permiso o access right, es una autorización para hacer una operación particular sobre un objeto.
Los permisos se codifican en 32 bits (access mask).
Permisos estándar:
- DELETE: eliminar el objeto.
- READ_CONTROL: acceso de lectura sobre el owner, group o DACL del security descriptor.
- WRITE_DAC: acceso de escritura a la DACL.
- WRITE_OWNER: permiso de escritura sobre dueño.
Permisos genéricos:
- GENERIC_READ
- GENERIC_WRITE
- GENERIC_EXECUTE
- GENERIC_ALL
Cada clase de objetos, mapea los permisos genéricos a permisos reales.

Owner

El dueño de un objeto se especifica con el SID del principal.
Es un principal.
Se asignan cuando el objeto es creado.
El dueño siempre tiene permiso de READ_CONTROL y WRITE_DAC.
Puedo “hacerme” dueño de un objeto si tengo el privilegio "Take ownership of files and other objects" (SeTakeOwnershipPrivilege).

Decisiones sobre acceso

Cada tipo de objeto tiene un manejador que se encarga de crearlos y verificar que un proceso tenga el derecho de usar dicho objeto (Policy Enforcement Point, PEP).
Control Acceso -> se hace invocando una función de decisión en el Security Reference Monitor (SRM) (Policy Decision Point, PDP).
Las decisiones de control de acceso toman como INPUT: el sujeto pidiendo acceso, el objeto al cual se quiere acceder y el tipo de acceso requerido (access mask).

Algoritmo #parcial

Entrada

el token del sujeto,
la ACL del objeto y,
la “access mask” solicitada (los permisos requeridos)

Decisión

a. Si no hay DACL (NULL DACL), el acceso es otorgado.
	(no es lo mismo que DACL vacío)
b. Si el sujeto es el dueño del objeto, entonces:
      Si la access mask contiene Read_Control o Write_DAC:
		 el acceso es otorgado.
	  Sino:
	     se construye una “access mask” de permisos
	     otorgados o garantizados y se busca en las
	     ACE de la DACL.
c. Para cada ACE de la DACL se compara el SID del sujeto con el de la ACE, pudiéndose dar 3 casos:
	  1. La ACE no contiene un SID que corresponda, 
	     entonces se saltea.
	  2. La ACE contiene un SID que corresponde y
	     especificando ACCESS DENIED, entonces se niega
	     el acceso y no se continúa el proceso.
	  3. La ACE contiene un SID que corresponde y
	     especificando ACCESS ALLOWED, entonces si la
	     access mask en la ACE, junto a las access mask
	     de todas las anteriores ACEs que matchearon,
	     contiene los permisos solicitados entonces se
	     permite el acceso y se termina, sino se continúa
	     buscando.

La regla de oro es que las ACEs negativas (access denied) toman precedencia sobre las positivas (access allowed), esto puede implementarse usando listas y colocando los DENY al inicio de la DACL. Esta es la forma de resolver conflictos en las ACE. #parcial

Distintos modos

Windows Access controls pueden usarse de distinta forma:

Impersonation: El proceso (subject) “inpersonates” el SID del usuario (principal) de su token.
Role-Centric: usamos grupos y alias para darle a un proceso los permisos para realizar su tarea.
Object-Centric: los objetos a nivel de las aplicaciones obtienen un SD (mucho mas complejo).

DACL

Es una lista de ACEs (access control entries).
Es posible unir propiedades en conjuntos.

Herencia de ACEs

Al crearse un nuevo objeto, se heredan del contenedor en el cual están.
Pasted image 20240509201216.png

Restricted Tokens

El control de acceso está referido (implícitamente) a usuarios.
Se puede implementar una variante de code-based access control usando restricted tokens.
Un proceso ejecutando con un restricted token es un restricted context.
Estos tokens eliminan privilegios de un token dado, son versiones limitadas de un access token.
Un proceso ejecutando con un “restricted token” se denomina “restricted context”.
Se pueden construir a partir de un access token del usuario:
- Deshabilitando grupos: no se eliminan, son marcados como USE_FOR_DENY_ONLY.
- Agregando un restricted SID representando la identidad y permisos del programa ejecutándose; este SID se usa en las ACL de los objetos para darle acceso al programa (sujeto).
- Eliminando privilegios.
restricted SIDs pueden crearse por:
- Programas y agregado a las ACLs de los recursos requeridos (object types).
- Tipo de objeto y agregado a los “restricted tokens”.

Contexto restringido

Los SIDs de grupos pueden deshabilitarse marcándolos como USE_FOR_DENY_ONLY.
Se puede usar cuando un thread del servidor impersona a un cliente
Por ejemplo, ejecuta en el contexto del token de acceso del cliente.
Mediante el agregado de un SID restringido al token, un proceso tiene acceso solamente si ambos el SID y el SID restringido tienen acceso.

Algoritmo de control de acceso

BOOLEAN RestrictedAccessCheck (Acl: ACL, DesiredAccess : AccessMask, RestrictedToken : AccessToken)
if (AccessCheck(Acl, DesiredAccess, RestrictedToken.PrincipalSids) && (AccessCheck(Acl, DesiredAccess, RestrictedToken.RestrictedSids) 
	return SUCCESS; 
else 
	return FAILURE;

Ejemplo

Pasted image 20240509201954.png

Extensiones de seguridad

Mandatory Integrity Control (MIC)

Nuevo conjunto de security principals llamados integrity levels (IL) que se agregan a los Access Token y ACLs:

Low
Medium
High
Se chequean los IL del sujeto y objeto al que se está accediendo.

User Access Control (UAC) o Least User Access (LUA)

Desarrollador marca aplicaciones que requieren privilegios elevados.
LSA es modificado para asignar dos tokens al momento de logon: filtered (restricted) y linked.
Aplicaciones ejecutan con filtered token.
Token con los privilegios completos (linked) es usado solo con aplicaciones marcadas que requieren privilegios elevados.
Usuarios sin privilegios de administrador ejecutan con medium IL, cuando el proceso eleva privilegios ejecuta con high IL.

Security Templates

Una herramienta muy util que proveen los sistemas Windows 2000 es la “Windows Configuration Tool Set”.
Provee un mecanismo centralizado para verificar y aplicar políticas de seguridad a un sistema Win2000.
Archivos de texto donde se especifican configuraciones de seguridad del sistema.
Podemos modificar, crear o exportar un template de seguridad usando los “snap-in” de la MS Management Console (MMC):
- Security Configuration and Analysis Tool
- Security templates
La aplicación de las políticas definidas en un security template, podemos aplicarlas usando:
- Group Policy Object (Domain Environment)
- secedit.exe command line utility (workgroup environment)

Gestión de logs y auditoria

Win2000 professional cuenta con capacidades importantes de auditoría.
- Logon events, account management, directory server access, object access, policy change, privilege use, process tracking, system events.
Archivos individuales pueden ser auditados.
Los eventos auditados los accedemos usando la herramienta “Event Viewer”.
El sistema de registro de eventos (log) almacena los datos estructurados en campos:
- “Type”, “User”, “Computer”, “Category”, etc
Provee una API para acceder en forma segura a la información de logs.
Contamos con acceso remoto desde otras computadoras con S.O. Windows.
No es sencillo hacer búsquedas de “texto libre” sobre los registros de eventos (solo usando los campos predefinidos).
No provee mecanismos para el almacenamiento de logs en un servidor central ….
A menos de incorporar soluciones extras (SCOM, System Center Opertation Manager), más costosas y complejas.

Laboratorio #parcial

PAM

Configuración especificada en archivos en /etc/pam.d. Se hacen las comprobaciones en el orden en que están listadas.

Ofrece flexibilidad y control tanto para el desarrollador como para el administrador de sistema.
Permite a los desarrolladores abstraerse de las labores de autenticación.

Flags de control de los PAM

required - Con este indicador de control, si el módulo tiene éxito, registra un éxito required y continúa comprobando los módulos siguientes. Si el módulo falla, y si éste es el primer fallo required, guarde el mensaje de error y continúe comprobando la pila. Si no es el primer fallo, siga comprobando la pila.
binding - Si el módulo tiene éxito y no ha fallado ningún módulo precedente marcado como required, omita los módulos restantes. Si se devuelve un fallo, registre un fallo required y continúe procesando la pila.
Es como required, pero marca el fin de la comprobación si es exitosa.
requisite - Con este indicador de control, si el módulo tiene éxito, se registra un éxito required y se continúa comprobando los módulos siguientes. Si el módulo falla, registra un fallo required, devuelve el mensaje de error del primer fallo required y omite cualquier comprobación adicional.
Es como required, pero marca el fin de la comprobación si falla.
optional - Con este indicador de control, si el módulo tiene éxito, registre un éxito optional y continúe comprobando la pila. Si el módulo falla, registre un fallo optional y continúe comprobando la pila.
No afecta el resultado final de la pila.
sufficient - Con esta bandera de control, si el módulo tiene éxito, y ningún módulo precedente que esté marcado como required ha fallado, entonces sáltese los módulos restantes. Si el módulo falla, registre un fallo de optional y continúe comprobando la pila.
Es como binding, pero los fallos no importan y se sigue.

Escalada de privilegios

Mitigación:

Mantener los sistemas actualizados.
Ejecutar aplicaciones con mínimos privilegios. Limitar los SUID/GUID.

Password Craking

Online: Hydra

Desventajas:

Como se lanzan cientos de pruebas, en los logs del sistema atacado quedarán múltiples líneas revelando nuestras intenciones.
Al tratarse de un ataque contra sistemas remotos se requiere comprobación mediante ensayo y error, la ejecución es lenta.
Según la configuración del sistema atacado, el ataque podría bloquear el acceso a las cuentas, delatando así las intenciones.

Local: John The Ripper

Ventajas:

Puede utilizarse sobre uno o varios sistemas para paralelizar las tareas.
Ninguna cuenta será bloqueada.
El proceso se llevará acabo localmente.
Desventajas:
Sólo es posible cuando se tiene acceso al hash de la contraseña.